Specifying Instruction-Set Architectures in HOL: A Primer

type, readers of the speci cation do not jump to the conclusion that, for example, the microprocessor adds correctly, when in fact it does not. { Using abstract types avoids the e ort of building a large infrastructure to support the type and its operations and the accompanying e ort of manipulating this infrastructure to get the proof completed if this infrastructure has little to do with what is being proven. We create an abstract representation using the abstract theory package described in [Win92]. The abstract representation is created by describing the signatures of the desired operations. The type variables used in those signatures are the uninterpreted types of the representation. Abstract representations can be used to specify n{bit words, the memory interface and other complex types that the designer wishes to consider primitive. As an example, the signature for the abstract n{bit word operations in theUinta speci cation is shown below:1 let ops_lemma = new_abstract_representation `OPS` [ `add`, ":(*wordn # *wordn) > *wordn"; `eqp`, ":(*wordn # *wordn) > bool"; `gtzp`, ":*wordn > bool"; `shl`, ":(*wordn # num) > *wordn); `val`, ":*wordn > num"; `wordn`, ":num > *wordn"; `subrange`, ":*wordn > (num # num) > *wordn"; ... ];; The signature gives an operation a name, add for example, and a type. The type for add declares it to be a binary function on n{bit words. The signature gives no other information about the operator. Of course, there are instances where more information is needed to complete the veri cation. In that case, we can also give a partial semantics of the operations. We call these semantics theory obligations and specify them using a predicate. The theory obligations for Uinta are shown in Figure 1. Notice that we require the arithmetic operators to commute, for example, but we require nothing else of them. This is the only necessary property for these operators to complete the veri cation of Uinta. On the other hand, the semantics of setbit and bit are more fully de ned as these operators play a more central role in the correct functioning of the microprocessor. The semantics are de ned algebraically by relating the operation of setbit, bit and other n{bit functions. Often the required partial semantics for the abstract representation will not be known at the time of speci cation, but will be developed during the veri cation. Thus, developing the theory obligations is an iterative process. 1 In the interest of brevity we eliminated many of the arithmetic and bit functions actually de ned in the abstract representation. new_theory_obligations (`Ops_thobs`, "Ops_thobs rep = (8 a (b:*wordn) . add rep (a,b) = (add rep (b,a))) ^ (8 a (b:*wordn) . band rep (a,b) = (band rep (b,a))) ^ (8 a (b:*wordn) . bxor rep (a,b) = (bxor rep (b,a))) ^ (8 a (b:*wordn) . bor rep (a,b) = (bor rep (b,a))) ^ (8 a (b:*wordn) . eqp rep (a,b) = (eqp rep (b,a))) ^ (8 n m w1 b . :(n = m) ) (bit rep m(setbit rep(n,w1,b)) = bit rep m w1)) ^ (8 m w1 b . (bit rep m(setbit rep(m,w1,b)) = b)) ^ (8 n m . (subrange rep (wordn rep 0) (n,m) = (wordn rep 0))) ^ (8 n . (val rep (wordn rep n) = n)) ^ (8 n m w1 b1 b2 . :(n = m) ) (setbit rep (m,(setbit rep(n,w1,b1),b2)) = setbit rep (n,(setbit rep(m,w1,b2),b1)))) ^ (8 b n w1 . setrange rep w1 (n,n) (repeat rep (1,b)) = setbit rep (n,w1,b))" );; Fig. 1. The Partial Semantics for Abstract n{bit Words. If we used the preceding abstract representation of n{bit words in the speci cation and veri cation of a microprocessor, we could not say, when we were all done, that the microprocessor correctly adds anything since the abstract representation does not de ne add in enough detail. What has been shown is that when the microprocessor fetches a certain opcode, the correct operands are fetched, the operation called add is performed and the result is stored in the correct place. The proof that the add operation is correct is orthogonal and done independently of the veri cation of the microprocessor. There are a number of things to keep in mind regarding the use of abstract representations for primitive type in computer architecture speci cations: { We have found that it is useful to separate abstract speci cations into smaller groups (such as the division between n{bit words and memory operations) because there are times when one wishes to instantiate the memory interface, for example, without building the infrastructure to instantiate n{bit words. { One must take care that the partial semantics of the abstract operators are indeed the desired semantics. When one gives the abstract speci cation of n{bit words, for example, one is assuming that concrete objects with those semantics exists and basing the rest of the proof on that assumption. One could easily create a semantics that is unrealizable and thus render the proof that depends on it useless. { One should keep the signature and theory obligations as small as possible for several reasons. First, smaller abstract representations are easier realized with a concrete type. Second, if the abstract representation contains only what is needed in the veri cation and no more, one can use it to see just what properties a concrete realization must have. As mentioned earlier, abstract type representations can be used to de ne the memory interface as well. Other primitive types that must usually be de ned include register indices, addresses, etc. 3 Instruction Set Syntax Instruction set syntax has often been ignored in formal microprocessor proofs and, at most, dealt with peripherally using diagrams, text, or names. For example, in most of the microprocessor speci cations referenced at the beginning of this paper, there is no formal mapping between the instruction mnemonic and the opcode. Similarly, the instruction format can only be deduced by examining the de nitions of the functions used to select portions of the n{bit word in the instruction register. The situation was even worse in speci cations that used abstract representation of primitive types. For example, in AVM{1, one can tell that somewhere in the ADD instruction there is a destination register index, but one cannot tell where it is in the word or how many bits it occupies. This situation need not be: we can formally describe the instruction mnemonics, describe the instruction formats, and map the instructions into opcodes. The mnemonics and format can be de ned using an abstract syntax. The abstract syntax of a microprocessor instruction set is usually simple enough to be de ned with a non-recursive data type speci cation using the define type function of HOL. For example, the speci cation of the abstract instruction set syntax for Uintais shown in Figure 2. Because we are using the HOL type de nition package, in addition to the syntax de nition, we can easily prove that each instruction is distinct and that the instruction set is total. We can also use the type de nition package to do case analysis on the instruction set and create recursive de nitions over the instruction set. For example, the following function selects the B source register index from those instructions that provide one: new_recursive_definition false Instruction_axiom `sel_Rb` "(sel_Rb (ADD Rd Ra Rb) = Rb) ^ (sel_Rb (SUB Rd Ra Rb) = Rb) ^ (sel_Rb (BAND Rd Ra Rb) = Rb) ^ (sel_Rb (BOR Rd Ra Rb) = Rb) ^ (sel_Rb (BXOR Rd Ra Rb) = Rb)" The de nition of the syntax shown in Figure 2 uses HOL type variables to represent the register index, 16{bit short words, and 26{bit address words. Their order in a particular production is meant to indicate the location of the operands operands for that instruction, although the formalization of this is done in the mapping between n{bit words and the abstract syntax (see below). Had we used let Instruction_axiom = define_type `Instruction` `Instruction = LDI *ri *ri *short j STI *ri *ri *short j LHI *ri *ri *short j ADD *ri *ri *ri j ADDI *ri *ri *short j SUB *ri *ri *ri j SUBI *ri *ri *short j ... JMP *word26 j JMPR *ri *short j JALI *ri *short j BEQ *ri *short j ... NOOP `;; Fig. 2. The Uinta Instruction Set Syntax. a concrete representation of n{bit words for our primitive operations, we would have used concrete representations for the register index, 16{bit shorts, and other data types as well since these are among the primitive types of which one needs to be aware. This abstract syntax is used in the architectural level speci cation, but not in lower levels of the proof hierarchy. An instruction at the architectural level is given by the abstract instruction syntax, but at lower levels in the hierarchy, the instruction is represented by an n{bit word. To complete the speci cation, not to mention the veri cation, one must provide a mapping from n{bit words to the abstract syntax. The following example shows part of the the decode function for Uinta: `def Decode_word orep w = let opc = (get_opcode orep w) and Rd = (get_rd orep w) and Ra = (get_rs1 orep w) and Rb = (get_rs2 orep w) and imm = (getimmed orep w) in (opc = LDI_OP) ! (LDI Rd Ra imm) j (opc = STI_OP) ! (STI Rd Ra imm) j (opc = ADD_OP) ! (ADD Rd Ra Rb) j ... (opc = BLTEZ_OP) ! (BLTEZ Ra imm) j % default % NOOP The above function, much reduced for brevity, shows how the abstract functions de ned earlier can be used to de ne a function that maps n-bit words into our abstract syntax. The constants, such as LDI OP, are de ned as `def LDI_OP = ^(octal 40) where octal is an ML function that converts octal numbers into objects with type :num for use in HOL. The selector functions get opcode, get rd, etc. are de ned using a range selector function from the abstract representation of n{bit words. For example, the de nition of get opcode shows where in the instruction word the opcode is located: `def get_opcode orep w = subrange orep w (31,26) The function get opcode could have been de ned as part of the abstract representation of n{bit words. However, by de ning it in terms of a more primitive function, subrange, we keep the abstract representation as small as possible and provide more information about the format of the instruction word. 4 The Semantic Domain The semantic domain describes the state of the microprocessor. We are concerned with the architectural level, so we describe only that state visible to the machine code programmer. Typically, the state visible at the architectural level includes the register le (or user registers on older machines), the program counter, any status registers, and the memory. If one thinks of the speci cation as a description of a processor, then including memory in the semantic domain can seem inconsistent, but when viewed as an architecture speci cation, the inclusion of the memory is more natural. Users of an architecture see and use the memory.